Why? What's the problem or the use case you are fixing?

The purpose of a DISTRO is to have an opinion, if your opinion differs from that, use a different DISTRO. Weak assignments in a DISTRO should be carefully considered, but the package format should be consistent no matter what.

Why? What's the problem or the use case you are fixing?

It doesn't cause any problems for now, but it could if you try to change the package manager in a KAs fragment.

The purpose of a DISTRO is to have an opinion, if your opinion differs from that, use a different DISTRO. Weak assignments in a DISTRO should be carefully considered, but the package format should be consistent no matter what.

When the meta-qcom-distro layer was created, it was using the distribution's package manager: package_ipk inherited from nodistro.
However, we started having problems with opkg a while ago and decided to switch to rpm.
However, this change was only made for the qcom-distro, while the nodistro remained with ipk.

What I want now is to standardize the package manager across the entire CI. What do you think we should do?

The purpose of a DISTRO is to have an opinion, if your opinion differs from that, use a different DISTRO. Weak assignments in a DISTRO should be carefully considered, but the package format should be consistent no matter what.

When the meta-qcom-distro layer was created, it was using the distribution's package manager: package_ipk inherited from nodistro. However, we started having problems with opkg a while ago and decided to switch to rpm. However, this change was only made for the qcom-distro, while the nodistro remained with ipk.

What I want now is to standardize the package manager across the entire CI. What do you think we should do?

I think we shouldn't be changing DISTRO settings in our CI. If a DISTRO is unsuited for our CI, we shouldn't use it, not pull a "It's Fedora, but we make it use .debs and musl" type of thing.

The point for nodistro is that we test our layer in using an upstream config to see if our own DISTRO is hiding issues, altering the upstream config severely hampers that effort. And "our CI is slow" is most certainly not a valid reason to change upstream configs.

So should we revert #144 ?

So should we revert #144 ?

Why? That change is qcom-distro specific, which is fine.

This pull request has been marked as stale due to 30 days of inactivity. To prevent automatic closure in 5 days, remove the stale label or add a comment. You can reopen a closed pull request at any time.

We are now using RPM also in nodistro qualcomm-linux/meta-qcom#2046. Therefore, what I intended by standardizing the package maneger is no longer necessary.